-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: reduce string concatenations #12735
Conversation
Will you be able to activate any eslint rules after this? |
@refack There are still ~20 cases like these ones I've abstained to change, at least till I think up some equally readable solutions. But these ones can be addressed with ESLint disabling comments. So |
You should add those (rule and comment exceptions) as it would provide extra motivation for this PR. |
I could do this if there is a minimal consensus if we should restrict this aspect from now on. Maybe some liberality is preferred here by the other collaborators) |
P.S. for things like these ones, I would do a multiline `` with replace `PUT /this HTTP/1.1
Content-Type: text/plain
Transfer-Encoding: chunked
4
ping
0
`.replace(/\r|\n|\r\n/g, '\r\n') |
Yes, this is only my opinion and I actually want to +1 |
@refack By the way, |
@vsemozhetbyt I love 2ality 🥇 |
I like the change but it's huge which makes it impractical to actually review. I went through the first 20-30 and they look good - but I don't feel comfortable with landing this unless someone goes through all changed content. |
Maybe we can divide: a reviewer can write down the last file reviewed, next reviewer can start from the next file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost went over all.
A few nits, some suggestions, and request to change path manipulation to path.join
@@ -34,11 +34,11 @@ let quit; | |||
|
|||
function startDebugger(scriptToDebug) { | |||
scriptToDebug = process.env.NODE_DEBUGGER_TEST_SCRIPT || | |||
common.fixturesDir + '/' + scriptToDebug; | |||
`${common.fixturesDir}/${scriptToDebug}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be path.join
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many such things in the tests. Should we address them in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separate PR is likely safer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a path.join
is important here, node modules always use /
(so it's not an OS compatibility concern). The main advantage of path.join
is that it abstracts joining complex paths, for concatenating two strings /
should be fine.
That said, if this view is contested - we can just leave it as is in the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO if we're touching this, so might as well "fix" it. There are multiple path concatenations done as strings, I feel they should all be changed, as path.join
is semantically different, even if string concat works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be ~300 re-editions in the PR...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your call @vsemozhetbyt if you have the energy do it. I'll review it.
If you say not this PR I'll retract those comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am in doubt if there is a minimum consensus for this. If there are 2-3 +1 and no strong -1, I can try to refactor with path.join()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like James and Benjamin, I’m fine with leaving this as-is. Leaving path.join()
refactors for a later PR sounds good to me. (If there’s consensus they should happen.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, seems like a job for a separate PR.
test/inspector/inspector-helper.js
Outdated
assert(message['result'], JSON.stringify(message) + ' (response to ' + | ||
JSON.stringify(this.messages_[id]) + ')'); | ||
assert(message['result'], `${JSON.stringify(message)} (response to ${ | ||
JSON.stringify(this.messages_[id])})`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+0
personally I'd rather you define as vars then do this trick
const msg_json = JSON.stringify(message);
const id_json = JSON.stringify(this.messages_[id]);
assert(message['result'], `${msg_json} (response to ${id_json})`);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created some new variables if this improved many places per file. But I also tried not to be too creative to not overload the diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a big fan of the trick... And otherwise you can't fit it in one line...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to @refack's suggestion, I think it definitely improves the readability.
test/inspector/inspector-helper.js
Outdated
assert(!message['error'], JSON.stringify(message) + ' (replying to ' + | ||
JSON.stringify(this.messages_[id]) + ')'); | ||
assert(!message['error'], `${JSON.stringify(message)} (replying to ${ | ||
JSON.stringify(this.messages_[id])})`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
test/inspector/inspector-helper.js
Outdated
@@ -215,10 +215,10 @@ TestSession.prototype.sendInspectorCommands = function(commands) { | |||
timeoutId = setTimeout(() => { | |||
let s = ''; | |||
for (const id in this.messages_) { | |||
s += id + ', '; | |||
s += `${id}, `; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const s = this.messages_.map(m => m.id).join(', ');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same: I would abstain from refactoring too deep: this will make reviewing and testing a lot more difficult.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I say, leave it as is, comment with TODO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to @refack's suggestion again. While you're here you might as well simplify, and it's a simple atomic change (so not too painful to review).
test/inspector/inspector-helper.js
Outdated
assert.fail('Messages without response: ' + | ||
s.substring(0, s.length - 2)); | ||
assert.fail( | ||
`Messages without response: ${s.substring(0, s.length - 2)}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If using map
, no need for substring
test/parallel/test-buffer-alloc.js
Outdated
expected.slice(120, 180)} \n${ | ||
expected.slice(180, 240)} \n${ | ||
expected.slice(240, 300)}\n${ | ||
expected.slice(300, 360)}\n`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-1
IMHO doesn't improve readability.
Maybe:
const expectedWhite =
`${expected.slice(0, 60)}\u0020
${expected.slice(60, 120)}\u0020
${expected.slice(120, 180)}\u0020
${expected.slice(180, 240)}\u0020
${expected.slice(240, 300)}
${expected.slice(300, 360)}
`;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may not be linted (indents).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely not a fan of multiline string literals. An array with a join might be an even better option.
const expectedWrite = [
expected.slice(0, 60),
expected.slice(60, 120),
expected.slice(120, 180),
expected.slice(180, 240),
expected.slice(240, 300),
expected.slice(300, 360)
].join(' \n') + '/n';
test/parallel/test-buffer-alloc.js
Outdated
expected.slice(120, 180)} \x00${ | ||
expected.slice(180, 240)} \x98${ | ||
expected.slice(240, 300)}\x03${ | ||
expected.slice(300, 360)}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
useTryCatchOpt | ||
].join(' '); | ||
cmdToExec += `${process.argv[0]} ${cmdLineOption ? cmdLineOption : ''} ${ | ||
process.argv[1]} child ${throwInDomainErrHandlerOpt} ${useTryCatchOpt}`; | ||
|
||
const child = exec(cmdToExec); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+-0
IMHO change the whole assembly to [].push(x).join(' ')
[ | ||
[entry, '../' + common.tmpDirName + '/cycles/root.js'] | ||
[entry, `../${common.tmpDirName}/cycles/root.js`] | ||
].forEach(function(t) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
path.join
test3(fs.createWriteStream(common.tmpDir + '/dummy3')); | ||
test1(fs.createWriteStream(`${common.tmpDir}/dummy1`)); | ||
test2(fs.createWriteStream(`${common.tmpDir}/dummy2`)); | ||
test3(fs.createWriteStream(`${common.tmpDir}/dummy3`)); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my progress marker
That's a huge PR indeed |
I've reverted changes in the |
I don't know what to do. To divide this PR in small ones, I lack criterions (by files number? by tests topics? other?). And I understand that other collaborators may not have my 2 free days to review all the changes (diff is very slow in addition). Feel free to say to close, I shall not consider this as a waste of time, this was a useful experience in many respects for me) |
IMHO Keep it. It's done, it's good. I'll go over it all. |
Removed requests to hoist stuff to |
O my) Conflicts resolved. New CI: https://ci.nodejs.org/job/node-test-pull-request/7758/ |
Some new conflicts resolved. Hopefully, the last CI: https://ci.nodejs.org/job/node-test-pull-request/7891/ |
Landed in 8b76c3e Sorry for all the conflicts it may cause... |
PR-URL: nodejs#12735 Refs: nodejs#12455 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
@vsemozhetbyt do you have the patience to backport this to |
@gibfahn I can try, but will anybody have the time to review? |
If you raise the PR I promise to review 😁 . Feel free to assign it to me. |
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test
Refs: #12455
This is not an exhaustive deliverance from all string concatenations: if a result looked too ugly and messy, I've abstained to change, so some concatenations still remain. I am not sure if we should to add
prefer-template: error
to test.eslintrc.yaml
, so I've also abstained from proposing, but let me know if this is discussable.Concerning reviews: #12735 (comment)
test/common.js
only)